help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?


From: rusi
Subject: Re: What's your favourite *under_publicized* editing feature ofEmacs?
Date: Mon, 28 Feb 2011 18:43:01 -0800 (PST)
User-agent: G2/1.0

On Mar 1, 4:31 am, Stefan Monnier <address@hidden> wrote:

> > I use nted
> > http://vsr.informatik.tu-chemnitz.de/~jan/nted/nted.xhtml
> > to enter music and I have a hell of a time versioning and diffing.
>
> Right: since this uses WYSIWYG you basically get the same problem: only
> nted can do the diff and merge-conflict display in a way that can make
> sense to the user.
> If you care about revision control, you're generally better off without
> WYSIWYG (I tend to think you're better off without it in any
> circumstance, but that's a different discussion ;-).
>

How do you enter *and play* music textually??? I would sure like a
tool that does not make me go clicking all over to get notes entered.
Something like abc http://abc.sourceforge.net/ or lilypond.
But I need something that can do this http://vimeo.com/16894001/ and
allows me to change the score live in front of a (singing) class.  Do
you know of any??

In fact I have spent some time wondering what it would mean to add
emacs' scripting functionality to nted.  In short, we would start by
factorizing emacs into 2 parts:
1. the 'pure lisp' scripting glue -- things like car, cdr, defun, cond
setq etc
2. the buffers, characters, input-methods etc that are *text* editor
specific.

For music, 2' would be provided with something like nted and then 1
can be 'married' to 2' to get a scriptable music editor/player.

With a text editor there is a clear set of 'atoms'
- "a key that is typed"
- "a character that is displayed."

For music there is no such set (at least to me) -- its too
multidimensional with staves, voices, real time rendering with etc

> > For Emacs (and such) this may be the way to go and is welcome.
> > For git (and such) however it may be preferable to have generic diff/
> > merge plugin capability; specifically for 'xml-container' formats like
> > odt and docx  but also more generically.
>
> Versioning documents in formats like odt is indeed a different issue:
> for diffs and merges you don't want to do it at the line-level of
> course, but neither do you necessarily want to do it at the XML level
> itself: maybe automatic merging can be done at the XML level, but when
> conflicts or diffs need to be shown to users, they have to be shown in
> terms that the user can understand and most users have no idea about
> odt's underlying XML representation other than that it exists.  So you
> need something like OpenOffice to do the diff for you.

Thats why I said plugin capability.  SW like openoffice (or nted)
would know how to diff 2 docs or merge 3.  The revision control
system's plugin would present it the 2 or 3 docs to diff or merge --
what vc does for emacs.


reply via email to

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