re: emacs and beginning of lines

re: emacs and beginning of lines

[Jude DaShiell]

When I read those messages about emacs not always going back to the 
correct start of line positions, I figured it might be useful to check on 
something.  I've started studying python and emacs has really good indent 
capabilities for its  default python mode.  However that default python 
mode on a line starting on position 5 on the screen also has this problem.  
If I get on a line like that and hit c-e first then hit c-a then check my 
line position, I land on position 1 not position 5 where the indent 
started.



jude <jdashiel@shellworld.net>

Re: emacs and beginning of lines

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

Jude DaShiell [2014-09-06 05:59:13 -04:00] wrote:

> However that default python mode on a line starting on position 5 on
> the screen also has this problem. If I get on a line like that and hit
> c-e first then hit c-a then check my line position, I land on position
> 1 not position 5 where the indent started.

Do you want M-m (back-to-indentation) command?


    M-m runs the command back-to-indentation, which is an interactive
    compiled Lisp function in `simple.el'.

    It is bound to M-m.

    (back-to-indentation)

    Move point to the first non-whitespace character on this line.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: emacs and beginning of lines

[Jude DaShiell]

M-m should work better I think, thanks. On Sat, 6 Sep 2014, Teemu Likonen 
wrote:

> Jude DaShiell [2014-09-06 05:59:13 -04:00] wrote:
> 
> > However that default python mode on a line starting on position 5 on
> > the screen also has this problem. If I get on a line like that and hit
> > c-e first then hit c-a then check my line position, I land on position
> > 1 not position 5 where the indent started.
> 
> Do you want M-m (back-to-indentation) command?
> 
> 
>     M-m runs the command back-to-indentation, which is an interactive
>     compiled Lisp function in `simple.el'.
> 
>     It is bound to M-m.
> 
>     (back-to-indentation)
> 
>     Move point to the first non-whitespace character on this line.
> 

jude <jdashiel@shellworld.net>

Re: emacs and beginning of lines

[Emanuel Berg]

Jude DaShiell <jdashiel@shellworld.net> writes:

> M-m should work better I think, thanks.

M-m is the default for `back-to-indentation', yes, but
it makes sense to DWIM-merge that with C-a as to me
intuitively it is the same.

I just now wrote a post on this issue (sort of) in
another thread - check they out, otherwise I'll just
offer you the source to try:

(defun back-to-dwim ()
  (interactive)
  (let ((point (point)))
    (back-to-indentation)
    (if (= point (point))
        (move-beginning-of-line nil) ))) ; ARG (nil = this line)

Yes, Python is one of the very few programming
languages that has compulsory indentation so I imagine
you would want really good support for that.

I'm a bit split on that issue. On the one hand, I
always indent my code pedantically. It is the first
thing I do if I ever get to continue work on some other
guy's code. Then, it is also a matter of learning what
is going on by making it look good. That works in the
bicycle repair shop as well. But the looks are as
important in themselves. ("May I indent your code?" is
an insult, perhaps the worst.)

On the other hand, I don't like the Python compulsory
approach and I would never stand for it either in C or
Lisp.

It is like a puzzle. You want a puzzle to be difficult
but you still don't want a puzzle with uniformly formed
pieces and the picture being a vast field with all-but
identical red and green flowers. It is good to de a
pedant in programming but you don't have to be pedantic
about it :)

-- 
underground experts united

Re: emacs and beginning of lines

[Marcin Borkowski]

Dnia 2014-09-06, o godz. 14:03:19
Teemu Likonen <tlikonen@iki.fi> napisał(a):

> Do you want M-m (back-to-indentation) command?

BTW: back-to-indentation seems to be broken with visual-line-mode; it
doesn't take into consideration, well, /visual/ lines.  One might
argue that it is a feature, but I think this is a bug: I guess that
visual-line-mode is primarily useful for editing texts in natural
languages (or markup languages, like LaTeX in my case), so the default
behavior of M-m doesn't make much sense.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: emacs and beginning of lines

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> BTW: back-to-indentation seems to be broken with
> visual-line-mode; it doesn't take into consideration,
> well, /visual/ lines. One might argue that it is a
> feature, but I think this is a bug: I guess that
> visual-line-mode is primarily useful for editing
> texts in natural languages

Yes, primarily that, like in plain text files. (Tho I
would recommend filling for that as well, as said.)

> (or markup languages, like LaTeX in my case)

Secondarily that, but for a .tex file you might as well
use auto-fill-mode as when you compile it (into a PDF)
that will be treated as unbroken lines.

I've found two minor complications. One is that, say
for this paragraph:

\def\realtimeenforcementsystem{Definition of
  {\bf real-time enforcement system}: The
  {\em real-time enforcement system}
  is the software that makes sure that the real-time
  tasks are executed in such a way that they are all

If you fill it, it may turn out like this:

\def\realtimeenforcementsystem{Definition of {\bf
  real-time enforcement system}: The {\em real-time
  enforcement system} is the software that makes sure
  that the real-time tasks are executed in such a way
  that they are all

As long as it doesn't break highlighting, it isn't that
much of an issue - still, I think the first version is
better.

If you make edits, then do M-q again, it may screw up
again and you have to fix it, again. There was a guy
who posted some sort of patch to this on
gnu.emacs.sources, but I don't remember how that worked
exactly. If he reads this, feel free to comment (of
course).

The second complication is that in the .pdf, it may
look like this "My friends told me" - say you want to
change that to "My associates" or whatever - and you
make a search for "My friends" - no hit! Because in the
source, it appears at the end of a line and there is a
"source line break" (but not PDF line break) right
after "My". A regexp search would do it, but it is
nothing I would like to do habitually and I wouldn't
intuitively think of that right away. Could be
automatized, perhaps...

Searching for stuff in LaTeX source can actually be
tedious for this reason, but on a larger scale as well,
because of the markup in general. But for words that
are bold, for example, you see they are bold instantly
(in the .pdf), but for line breaks it doesn't show that
way.

Is there a LaTeX submode for hiding markup or search
function to disregard it?

Those and other reasons is why I always stick to plain
text unless for really ambitious documents like thesis
and books/manuals that are intended for printing. It is
just so much more overhead than the simple and sweet
science of putting together plain text files and
messages. It is also more honest: if you are a moron,
it'll show. There is just no where to hide between
fancy markup.

-- 
underground experts united

Re: emacs and beginning of lines

[Marcin Borkowski]

Dnia 2014-09-07, o godz. 23:32:25
Emanuel Berg <embe8573@student.uu.se> napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > BTW: back-to-indentation seems to be broken with
> > visual-line-mode; it doesn't take into consideration,
> > well, /visual/ lines. One might argue that it is a
> > feature, but I think this is a bug: I guess that
> > visual-line-mode is primarily useful for editing
> > texts in natural languages
> 
> Yes, primarily that, like in plain text files. (Tho I
> would recommend filling for that as well, as said.)

If you use a VCS and look at a diff from time to time, filling might
be a bad idea.  (Though visual-line-mode is not helpful then, either.)

> > (or markup languages, like LaTeX in my case)
> 
> Secondarily that, but for a .tex file you might as well
> use auto-fill-mode as when you compile it (into a PDF)
> that will be treated as unbroken lines.

As above.

> The second complication is that in the .pdf, it may
> look like this "My friends told me" - say you want to
> change that to "My associates" or whatever - and you
> make a search for "My friends" - no hit! Because in the
> source, it appears at the end of a line and there is a
> "source line break" (but not PDF line break) right
> after "My". A regexp search would do it, but it is
> nothing I would like to do habitually and I wouldn't
> intuitively think of that right away. Could be
> automatized, perhaps...

I vaguely remember reading somewhere that Emacs 24.4 solves this...

> Searching for stuff in LaTeX source can actually be
> tedious for this reason, but on a larger scale as well,
> because of the markup in general. But for words that
> are bold, for example, you see they are bold instantly
> (in the .pdf), but for line breaks it doesn't show that
> way.

True.

> Is there a LaTeX submode for hiding markup or search
> function to disregard it?

That would be cool.  Hiding is much easier, AFAIK AUCTeX supports
that.  Searching might be tricky, though.  (If all you need is
searching for a sequence of /words/, it would probably make it
easier.  Also, you could have a second buffer with all your document
"detexified" and somehow link it to the main one...  A bit of overhead
with updating it, but probably doable.)

> Those and other reasons is why I always stick to plain
> text unless for really ambitious documents like thesis
> and books/manuals that are intended for printing. It is
> just so much more overhead than the simple and sweet
> science of putting together plain text files and
> messages. It is also more honest: if you are a moron,
> it'll show. There is just no where to hide between
> fancy markup.

Fair enough.  OTOH, some things are easier to mark up (at least for
me) in LaTeX than, say, in Org-mode.  But it might be the question of
experience and my habits...

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: emacs and beginning of lines

[Yuri Khan]

On Mon, Sep 8, 2014 at 4:17 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl> wrote:
> Dnia 2014-09-07, o godz. 23:32:25
> Emanuel Berg <embe8573@student.uu.se> napisał(a):
>
>> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>>
>> > BTW: back-to-indentation seems to be broken with
>> > visual-line-mode; it doesn't take into consideration,
>> > well, /visual/ lines. One might argue that it is a
>> > feature, but I think this is a bug: I guess that
>> > visual-line-mode is primarily useful for editing
>> > texts in natural languages
>>
>> Yes, primarily that, like in plain text files. (Tho I
>> would recommend filling for that as well, as said.)
>
> If you use a VCS and look at a diff from time to time, filling might
> be a bad idea.  (Though visual-line-mode is not helpful then, either.)
>
>> > (or markup languages, like LaTeX in my case)
>>
>> Secondarily that, but for a .tex file you might as well
>> use auto-fill-mode as when you compile it (into a PDF)
>> that will be treated as unbroken lines.
>
> As above.
>
>> The second complication is that in the .pdf, it may
>> look like this "My friends told me" - say you want to
>> change that to "My associates" or whatever - and you
>> make a search for "My friends" - no hit! Because in the
>> source, it appears at the end of a line and there is a
>> "source line break" (but not PDF line break) right
>> after "My". A regexp search would do it, but it is
>> nothing I would like to do habitually and I wouldn't
>> intuitively think of that right away. Could be
>> automatized, perhaps...
>
> I vaguely remember reading somewhere that Emacs 24.4 solves this...
>
>> Searching for stuff in LaTeX source can actually be
>> tedious for this reason, but on a larger scale as well,
>> because of the markup in general. But for words that
>> are bold, for example, you see they are bold instantly
>> (in the .pdf), but for line breaks it doesn't show that
>> way.
>
> True.
>
>> Is there a LaTeX submode for hiding markup or search
>> function to disregard it?
>
> That would be cool.  Hiding is much easier, AFAIK AUCTeX supports
> that.  Searching might be tricky, though.  (If all you need is
> searching for a sequence of /words/, it would probably make it
> easier.  Also, you could have a second buffer with all your document
> "detexified" and somehow link it to the main one...  A bit of overhead
> with updating it, but probably doable.)
>
>> Those and other reasons is why I always stick to plain
>> text unless for really ambitious documents like thesis
>> and books/manuals that are intended for printing. It is
>> just so much more overhead than the simple and sweet
>> science of putting together plain text files and
>> messages. It is also more honest: if you are a moron,
>> it'll show. There is just no where to hide between
>> fancy markup.
>
> Fair enough.  OTOH, some things are easier to mark up (at least for
> me) in LaTeX than, say, in Org-mode.  But it might be the question of
> experience and my habits...
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>

Re: emacs and beginning of lines

[Yuri Khan]

[sorry for previous post — misclicked a button]

On Mon, Sep 8, 2014 at 4:17 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl> wrote:

> If you use a VCS and look at a diff from time to time, filling might
> be a bad idea.  (Though visual-line-mode is not helpful then, either.)

+1.
For diff-friendly marked-up text,
it probably makes sense
to semi-arbitrarily split lines
so that each line is more or less a logical unit,
like this reply.

Re: emacs and beginning of lines

[Marcin Borkowski]

Dnia 2014-09-08, o godz. 18:34:09
Yuri Khan <yuri.v.khan@gmail.com> napisał(a):

> [sorry for previous post — misclicked a button]
> 
> On Mon, Sep 8, 2014 at 4:17 PM, Marcin Borkowski
> <mbork@wmi.amu.edu.pl> wrote:
> 
> > If you use a VCS and look at a diff from time to time, filling might
> > be a bad idea.  (Though visual-line-mode is not helpful then,
> > either.)
> 
> +1.
> For diff-friendly marked-up text,
> it probably makes sense
> to semi-arbitrarily split lines
> so that each line is more or less a logical unit,
> like this reply.

Exactly.

Now I started to wonder how to make an "auto-fill on steroids", which
would do that for me...

It is not as silly as it sounds.  I have a friend who does some
research about automatic translation, language analysis and correction
etc.  I am fairly confident that something like this could work.  Of
course, it would not work 100% of the time, but for that, even 80%
might be fine.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: emacs and beginning of lines

[Stefan Monnier]

>> > If you use a VCS and look at a diff from time to time, filling might
>> > be a bad idea.  (Though visual-line-mode is not helpful then,
>> > either.)

FWIW, I use diff-mode's `diff-refine-hunk' to help with that.


        Stefan

Re: emacs and beginning of lines

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I use diff-mode's `diff-refine-hunk' to help
> with that.

Yeah, it sounds like it is better to do such a thing on
a mode basis. That's why there are modes :)

-- 
underground experts united

Re: emacs and beginning of lines

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> If you use a VCS and look at a diff from time to
> time, filling might be a bad idea. (Though
> visual-line-mode is not helpful then, either.)

Indeed, there are many times - notably all programming
and configuration modes - where you don't want filling
and absolutely not automatically so.

>> Is there a LaTeX submode for hiding markup or search
>> function to disregard it?
>
> That would be cool. Hiding is much easier, AFAIK
> AUCTeX supports that. Searching might be tricky,
> though. (If all you need is searching for a sequence
> of /words/, it would probably make it easier.

If you can hide markup, what remains to do is a search
function that treaties newlines and whitespace the
same, as it can appear as a newline in the source, but
a whitespace in the .pdf. Very doable.

If you tell me how to hide in AUCTeX I'll install that
instantly and try it.

> Fair enough. OTOH, some things are easier to mark up
> (at least for me) in LaTeX than, say, in Org-mode.
> But it might be the question of experience and my
> habits...

I never tried Org-mode but I heard a lot about it so I
assume it is great. However for me personally I'm a bit
of a fanatic. I don't want any transitions between
representations. I'm not convinced I can write better
HTML, LaTeX, C++ documentation, etc. than Org-mode or
some other tool. But I'm not convinced of the opposite
either. And what tips the scale is that, if I run into
a problem with LaTeX/HTML/etc. I go right to the source
and fix it. If I used a [semi-]WYSIWYG, where would I
go? No, I'll stay close to the heat!

-- 
underground experts united

Re: emacs and beginning of lines

[Marcin Borkowski]

Dnia 2014-09-09, o godz. 00:10:58
Emanuel Berg <embe8573@student.uu.se> napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > If you use a VCS and look at a diff from time to
> > time, filling might be a bad idea. (Though
> > visual-line-mode is not helpful then, either.)
> 
> Indeed, there are many times - notably all programming
> and configuration modes - where you don't want filling
> and absolutely not automatically so.

Is LaTeX mode a programming one? ;-)

> >> Is there a LaTeX submode for hiding markup or search
> >> function to disregard it?
> >
> > That would be cool. Hiding is much easier, AFAIK
> > AUCTeX supports that. Searching might be tricky,
> > though. (If all you need is searching for a sequence
> > of /words/, it would probably make it easier.
> 
> If you can hide markup, what remains to do is a search
> function that treaties newlines and whitespace the
> same, as it can appear as a newline in the source, but
> a whitespace in the .pdf. Very doable.
> 
> If you tell me how to hide in AUCTeX I'll install that
> instantly and try it.

https://www.gnu.org/software/auctex/manual/auctex/Folding.html

> > Fair enough. OTOH, some things are easier to mark up
> > (at least for me) in LaTeX than, say, in Org-mode.
> > But it might be the question of experience and my
> > habits...
> 
> I never tried Org-mode but I heard a lot about it so I
> assume it is great. However for me personally I'm a bit
> of a fanatic. I don't want any transitions between
> representations. I'm not convinced I can write better
> HTML, LaTeX, C++ documentation, etc. than Org-mode or
> some other tool. But I'm not convinced of the opposite
> either. And what tips the scale is that, if I run into
> a problem with LaTeX/HTML/etc. I go right to the source
> and fix it. If I used a [semi-]WYSIWYG, where would I
> go? No, I'll stay close to the heat!

I totally agree - especially with LaTeX, which I know very well.  I
tried to write a scientific article in Org-mode, got immediately
frustrated (not Org's fault - the reason was that it was not LaTeX;))
and switched back to LaTeX.

However, if I'm doing a document which contains TODO items, deadlines
etc., then the ability to export it to html (so I can send it to a
non-Emacs-savvy friend, for instance) is a big win.

And Org's tables - exportable to LaTeX & HTML - are really, really
great.  One time I had a table in LaTeX - two rows and lots of columns
- and needed to transpose it.  Good luck, unless you convert it to
Org-mode (manually, but fast due to string replacing), then transpose
it in Org (one command) and export back to LaTeX's tabular.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

more LaTeX (was: Re: emacs and beginning of lines)

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

>>> If you use a VCS and look at a diff from time to >
>>> time, filling might be a bad idea. (Though >
>>> visual-line-mode is not helpful then, either.)
>> Indeed, there are many times - notably all
>> programming and configuration modes - where you
>> don't want filling and absolutely not automatically
>> so.
>
> Is LaTeX mode a programming one? ;-)

LaTeX is definitely programming, but it is not
general-purpose programming (like C), or data-oriented
programming (like SQL), or anything like that.

I think the term is "domain-specific" and the domain is
typesetting documents and arranging material in
structured ways.

When I wrote what you quote, I meant general-purpose,
like C. But now that you say it, LaTeX offers a
borderline case: the programming parts of it, I don't
want to be filled, but I want the text part of it to be
(perhaps with the modification I suggested).

HTML on the other hand, I don't consider
programming but as with LaTeX, the text parts of an
.html file I would like filled, but not the tags that
set (and should so reflect) structure.

> And Org's tables - exportable to LaTeX & HTML - are
> really, really great. One time I had a table in LaTeX
> - two rows and lots of columns - and needed to
> transpose it. Good luck, unless you convert it to
> Org-mode (manually, but fast due to string
> replacing), then transpose it in Org (one command)
> and export back to LaTeX's tabular.

Stuff like that is great - when they work :)

-- 
underground experts united

Re: more LaTeX (was: Re: emacs and beginning of lines)

[Marcin Borkowski]

Dnia 2014-09-09, o godz. 22:02:02
Emanuel Berg <embe8573@student.uu.se> napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> >>> If you use a VCS and look at a diff from time to >
> >>> time, filling might be a bad idea. (Though >
> >>> visual-line-mode is not helpful then, either.)
> >> Indeed, there are many times - notably all
> >> programming and configuration modes - where you
> >> don't want filling and absolutely not automatically
> >> so.
> >
> > Is LaTeX mode a programming one? ;-)
> 
> LaTeX is definitely programming, but it is not
> general-purpose programming (like C), or data-oriented
> programming (like SQL), or anything like that.
> 
> I think the term is "domain-specific" and the domain is
> typesetting documents and arranging material in
> structured ways.
> 
> When I wrote what you quote, I meant general-purpose,
> like C. But now that you say it, LaTeX offers a
> borderline case: the programming parts of it, I don't
> want to be filled, but I want the text part of it to be
> (perhaps with the modification I suggested).

How do you decide which is which?

> HTML on the other hand, I don't consider
> programming but as with LaTeX, the text parts of an
> .html file I would like filled, but not the tags that
> set (and should so reflect) structure.

True.

Doesn't the difference between TeX and HTML you mean here lie in the
fact that TeX is Turing-complete and HTML is not?

See here (when you run out of real problems, that is;-)):
http://tex.stackexchange.com/questions/58042/

Also, search for "basix" on that very page.  (Only for people with
strong nerves.)

And there are a few numerical engines, a few drawing libraries, one
regex library and *a lot* of other things /programmed/ in TeX.  (I
read an article about some LaTeX code generating tests in differential
equations.  With solutions.  Though it didn't actually solve them, it
first chose the solutions (pseudo-randomly) and then generated an
equation with that very solution.)  So while it is indeed a
domain-specific language, it /can/ be coerced to doing really strange
things.  (Also, as a side-note for Lispers: TeX has macros which are
"expanded", but it doesn't have functions which would be "called".
This means in particular that you don't need loops in the language -
you can /implement/ them.  And you can change the order of expansion,
which is left-to-right by default, to a right-to-left one, though only
temporarily, for the next two tokens.  Actually, this is extremely
useful.  And btw: macro expansion happens at a different moment than
/assignments/, that is, state changes.  And writing to external files
happens at yet another moment (at least usually, it doesn't have to if
you explicitly demand that it doesn't).  And due to the catcode
mechanism you can pretty much redefine all of TeX syntax on the fly.
One guy used this to build an XML parser /entirely in TeX/.  Yes, TeX
is /not/ a "normal" programming language.)

> > And Org's tables - exportable to LaTeX & HTML - are
> > really, really great. One time I had a table in LaTeX
> > - two rows and lots of columns - and needed to
> > transpose it. Good luck, unless you convert it to
> > Org-mode (manually, but fast due to string
> > replacing), then transpose it in Org (one command)
> > and export back to LaTeX's tabular.
> 
> Stuff like that is great - when they work :)

Also true.

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: more LaTeX (was: Re: emacs and beginning of lines)

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

>> When I wrote what you quote, I meant
>> general-purpose, like C. But now that you say it,
>> LaTeX offers a borderline case: the programming
>> parts of it, I don't want to be filled, but I want
>> the text part of it to be (perhaps with the
>> modification I suggested).
>
> How do you decide which is which?

It has to be based on where the point is and what is
before/after it.

> Doesn't the difference between TeX and HTML you mean
> here lie in the fact that TeX is Turing-complete and
> HTML is not?

Well, Turing-complete is CS lingo and I only did CS at
the university... But what I remember is that it wasn't
easy to apply those paradigms and classification to
technology, not then and not now. Feel free to try,
tho.

No, I think HTML isn't programming because of the lack
of algorithms. HTML is also domain-specific, marking-up
text so that it can be displayed and interlinked in
certain ways. But where you can do seemingly anything
in LaTeX HTML is very limited when it comes to logic
and "execution" flow. It is just a 1:1 textual
representation of what will turn up in the browser. But
actually that doesn't have to be bad. I like static web
pages that only present textual material, with a couple
of images, and a link to the "next" section. So even
though LaTeX seems to be much more powerful than HTML,
I don't wish for a "LaTeX-web"...

> And there are a few numerical engines, a few drawing
> libraries, one regex library and *a lot* of other
> things /programmed/ in TeX.

Yes. This is the coolest thing I did in LaTeX:

http://user.it.uu.se/~embe8573/about/matte.pdf

(But it doesn't contain anything dynamic.)

But, I did a CV once which used this chunk of code
(which I didn't wrote) to automatically update my age
(ha! how depressing to have to do that each year while
the rest of the CV stays the same...)

http://user.it.uu.se/~embe8573/latex/year.tex

But it is a good example. I think the programming in
LaTeX is good, and probably it will be the most useful
with and around documents and typesetting.

> (I read an article about some LaTeX code generating
> tests in differential equations. With solutions.
> Though it didn't actually solve them, it first chose
> the solutions (pseudo-randomly) and then generated an
> equation with that very solution.) So while it is
> indeed a domain-specific language, it /can/ be
> coerced to doing really strange things.

Yeah, it reminds me of groff (roff) which is also like
that. But just because you can do lots in both doesn't
mean a more modern solution isn't preferable all the
same (like C, walkie-talkies, and e-mails).

-- 
underground experts united

Re: more LaTeX (was: Re: emacs and beginning of lines)

[Marcin Borkowski]

Dnia 2014-09-10, o godz. 03:12:09
Emanuel Berg <embe8573@student.uu.se> napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> >> When I wrote what you quote, I meant
> >> general-purpose, like C. But now that you say it,
> >> LaTeX offers a borderline case: the programming
> >> parts of it, I don't want to be filled, but I want
> >> the text part of it to be (perhaps with the
> >> modification I suggested).
> >
> > How do you decide which is which?
> 
> It has to be based on where the point is and what is
> before/after it.

No, I mean that with some documents it might be non-obvious whether
the fragment the point is in is a text or programming one.

> > Doesn't the difference between TeX and HTML you mean
> > here lie in the fact that TeX is Turing-complete and
> > HTML is not?
> 
> Well, Turing-complete is CS lingo and I only did CS at
> the university... But what I remember is that it wasn't
> easy to apply those paradigms and classification to
> technology, not then and not now. Feel free to try,
> tho.
> 
> No, I think HTML isn't programming because of the lack
> of algorithms. HTML is also domain-specific, marking-up
> text so that it can be displayed and interlinked in
> certain ways. But where you can do seemingly anything
> in LaTeX HTML is very limited when it comes to logic
> and "execution" flow. It is just a 1:1 textual
> representation of what will turn up in the browser. But
> actually that doesn't have to be bad. I like static web
> pages that only present textual material, with a couple
> of images, and a link to the "next" section. So even
> though LaTeX seems to be much more powerful than HTML,
> I don't wish for a "LaTeX-web"...

Well, it seems that you just expressed the difference between
Turing-complete and the rest in an informal way;-).

> > And there are a few numerical engines, a few drawing
> > libraries, one regex library and *a lot* of other
> > things /programmed/ in TeX.
> 
> Yes. This is the coolest thing I did in LaTeX:
> 
> http://user.it.uu.se/~embe8573/about/matte.pdf
> 
> (But it doesn't contain anything dynamic.)

Nice, especially the QR-code;).

> But, I did a CV once which used this chunk of code
> (which I didn't wrote) to automatically update my age
> (ha! how depressing to have to do that each year while
> the rest of the CV stays the same...)
> 
> http://user.it.uu.se/~embe8573/latex/year.tex

Very nice, too!

> But it is a good example. I think the programming in
> LaTeX is good, and probably it will be the most useful
> with and around documents and typesetting.
> 
> > (I read an article about some LaTeX code generating
> > tests in differential equations. With solutions.
> > Though it didn't actually solve them, it first chose
> > the solutions (pseudo-randomly) and then generated an
> > equation with that very solution.) So while it is
> > indeed a domain-specific language, it /can/ be
> > coerced to doing really strange things.
> 
> Yeah, it reminds me of groff (roff) which is also like
> that. But just because you can do lots in both doesn't
> mean a more modern solution isn't preferable all the
> same (like C, walkie-talkies, and e-mails).

That's why LuaTeX is the cool new thing in the TeX world.  (Well,
maybe no longer "new", it's around for almost 10 years now, but it has
been gaining momentum steadily, and is being more and more widely
adopted.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: more LaTeX (was: Re: emacs and beginning of lines)

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> No, I mean that with some documents it might be
> non-obvious whether the fragment the point is in is a
> text or programming one.

No, I understood, but that is the only way it could be
possible. How else?

But I think this might be a non-problem in practice. I
did lots of homepages and I never experienced this as a
problem. And I don't remember ever thinking of it
either, so it really cannot be a problem.

Perhaps when you do <html> tags you kind of are
inclined to add new rows to reflect structure, so those
rows never overflow the fill-column. Then when you
start to type the contents of the file, and you get
auto filling as usual.

Or perhaps I just enabled/disabled auto-filling -
usually, setting up the structure is fast. Writing the
contents take more time. It is not unthinkable to do
the <html> without filling, then switch it on and start
to type.

And that would work for LaTeX as well. So perhaps this
isn't a problem after all.

Never heard of LuaTeX but it doesn't supprise me because
Lua seems to be like a "glue" language (perhaps as Perl
used to be) that just appears and sticks between the
bigger and bulkier building blocks...

-- 
underground experts united

Re: more LaTeX (was: Re: emacs and beginning of lines)

[Marcin Borkowski]

Dnia 2014-09-10, o godz. 23:55:16
Emanuel Berg <embe8573@student.uu.se> napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > No, I mean that with some documents it might be
> > non-obvious whether the fragment the point is in is a
> > text or programming one.
> 
> No, I understood, but that is the only way it could be
> possible. How else?
> 
> But I think this might be a non-problem in practice. I
> did lots of homepages and I never experienced this as a
> problem. And I don't remember ever thinking of it
> either, so it really cannot be a problem.

Well, you're probably right.  What I meant is this: some people use
TeX macros as "templates" to fill in some repetitive text.  Pieces of
TeX documents with such macros seem to be "programming" and "text" at
the same time...  Though this is not *that* common practice.

> Never heard of LuaTeX but it doesn't supprise me because
> Lua seems to be like a "glue" language (perhaps as Perl
> used to be) that just appears and sticks between the
> bigger and bulkier building blocks...

Agreed.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University