Re: [NEWBIE] Questions

Re: [NEWBIE] Questions

[Kai Großjohann]

Robert Pollard <rpollard@apple.com> writes:

> 1.	Is there a way to adjust the indent space provided by the
>           auto-fill functionality between the topic number and the
>           text.  As in the following example:
> 	1.   lkajsdf lsdfl sadfl dfljasldflkjsdflk asld fls
>                  jsdfj asdfl lasdflj asdflj lsdf l jasdf lj sf  s
> 	Is there a way to adjust the space between the number 1. and
> 	the text? It appears to be a default amount.

You have to type it yourself.  Hm.  And when you then hit M-q, it
gets deleted, I think.  Let me try...

1.  lskdjf lkdjf lkdjf ldkfj ldfkjsldf kjsd lfksjd flksdjf lkdsjf
            lkdfj ldfkjld fkjsd lfksjdf lkj

Yep.  Paragraph looked as follows before I hit M-q:

1.          lskdjf lkdjf lkdjf ldkfj ldfkjsldf kjsd lfksjd flksdjf
            lkdsjf lkdfj ldfkjld fkjsd lfksjdf lkj

The two spaces after the "1." come from the fact that Emacs thinks
it's a sentence-end period and hence it makes two spaces.  Emacs
always assumes two spaces after a sentence, when you do M-q.

> 2.	If you have an outline and you need to move topics around is
>           there a way to renumber the topics?
> 	i.e.
> 	2.    lkjasdf alkjdasf alsdf alsdjfl asldf
> 	1.    asdfsld fl sadf ls dfl lasdfl asdf
> 	3.    kljasdf lasdjf ljasdf asdj flkj asdf

Maybe someone has written a Lisp package to do this.  I vaguely
recall something like this.  Maybe you can look in the Emacs Lisp
List?  http://www.anc.ed.ac.uk/~stephen/emacs/ell.html

> 3.	Why would a auto-fill not format the paragraph the way it does
>           99% of the other topics?
> 	i.e.
> 	The way it normally formats the paragraphs is:
> 	1.   asdfj asdfjljasdf lkjsdfj slkdjflj sdf sdfj lsdjf
> 	      sdf ksdf ;sadkf; ksdfk;sldk f;lsdl f;slk df;lask f
> 	On 2 occasions it formatted like:
> 	1.   sjdfj asdfsldjfljasld flkj asdfj alsdj fkasdlfj las
> 	sdjflasdjf lkjsdfk asdj lksdjflk asdlkf lsflk sdlfk sl
> 	I had to manually insert the tab/spaces for the second line.

It depends on the input.  Hitting M-q takes the spaces from the
second line of the paragraph.  And paragraphs, as you know, are
delimited by empty lines.  So suppose you have this:

1.  lskdjf
    sldkjf
2.  slkdfj

Then if you add another line after the third one (via auto-fill), the
line will start with four spaces.  But if you start with the
following situation, it will start with no space:

1.  lskdjf
lskdjf
2.  lskdjf

> 4.	I prefer not to have the paragraph indicators as a line feed
>           for end of the paragraph as it appears to be on default.

There is paragraph-indent-text-mode.  It assumes that a line starting
with whitespace starts a paragraph.

> I much prefer a carriage return to indicate the end of the
> paragraph.  As it stands, you have to have a blank line between
> paragraphs to indicate the end of the paragraph.

I don't understand this.  Emacs almost never uses carriage return
(^M) in a buffer.  And even inside a paragraph, every line ends with
a newline.

There is longlines.el which can remove "superfluous" newlines
(within paragraphs) when writing the file and it re-adds them when
reading the file.

> 	2.	Why is there a different value for global and the
>                   current buffer?

Depending on the mode, it makes sense to have a different definition
of the start of a paragraph.  For example, when editing itemized
environments in LaTeX, like so:

\begin{itemize}
\item first item
\item second item.  This one is longer and has more than one
  line.
\item third item.
\end{itemize}

Then it would be good to consider each item a paragraph, even though
they are not delimited by empty lines.  So LaTeX mode sets up
paragraph-start and paragraph-separate to make this happen.

> It appears there may be some kind of continuation pattern being used
> for each variable.  I do understand basic regular expressions but I
> don't fully understand these patterns.

Continuation pattern?

> 5.	I am running version 21.2.1 under Cygwin on an Intel system.
>           Certain key equivalents that I have gotten used to over the
>           time that I have been using Emacs are not working anymore.
>           I have to type the commands in instead.
> They are:
> C-x C-c	Quit Emacs
> C-h v	Describe a variable
> C-h i		Info docs
> C-<spc>	Set a mark
>
> Why would these key equivalents not work?  This is my first time for
> using Emacs in Cygwin but I thought the key equivalents would be the
> same on all systems.

I have no idea why they might fail.

Maybe you can use NT-Emacs, a native Windows executable?
http://www.gnu.org/software/emacs/windows/ntemacs.html
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: [NEWBIE] Questions

[Robert Pollard]

On Saturday, April 12, 2003, at 02:26 PM, Kai Großjohann wrote:

> Robert Pollard <rpollard@apple.com> writes:
>
>
> The two spaces after the "1." come from the fact that Emacs thinks
> it's a sentence-end period and hence it makes two spaces.  Emacs
> always assumes two spaces after a sentence, when you do M-q.

Are there variables that allow you to indicate what pattern an end of 
sentence should follow?  It seems this pattern isn't specific enough.  
If I indicate that a sentence usually isn't started with a number and a 
period on a new line then that should be enough to get it to do this 
only when it is a valid sentence, correct?

>> I much prefer a carriage return to indicate the end of the
>> paragraph.  As it stands, you have to have a blank line between
>> paragraphs to indicate the end of the paragraph.
>
> I don't understand this.  Emacs almost never uses carriage return
> (^M) in a buffer.  And even inside a paragraph, every line ends with
> a newline.
>
> There is longlines.el which can remove "superfluous" newlines
> (within paragraphs) when writing the file and it re-adds them when
> reading the file.

Using "carriage return" was word processor speak.  I actually didn't 
know what Emacs uses for end of line/paragraph when you hit the return 
key.  Since looking at paragraph-start and paragraph-separate I come to 
the conclusion that it is looking for a line feed "\f" for 
paragraph-separate and a carriage return and line feed "\n\f" for 
paragraph-start.  Is this correct?  If not what does \n and \f mean?


>> It appears there may be some kind of continuation pattern being used
>> for each variable.  I do understand basic regular expressions but I
>> don't fully understand these patterns.
>
> Continuation pattern?

The info docs said something about changing both variables if you 
change one.  I assumed this meant that both variable definitions 
together consisted of what makes up the end of a paragraph?  Is this 
not correct?

> [snip]
>> Why would these key equivalents not work?  This is my first time for
>> using Emacs in Cygwin but I thought the key equivalents would be the
>> same on all systems.
>
> I have no idea why they might fail.

To quote a poster who sent me the answer directly:
"This problem, with this particular key combination, is indeed
frequently asked about, but I don't know that it's addressed in any
FAQ.  Anyway: edit c:\cygwin\cygwin.bat, and add the line

         set CYGWIN=tty

before the call to `bash'."


Thank you very much for your time,

Robert Pollard

Re: [NEWBIE] Questions

[Kai Großjohann]

Robert Pollard <rpollard@apple.com> writes:

> On Saturday, April 12, 2003, at 02:26 PM, Kai Großjohann wrote:
>
>> Robert Pollard <rpollard@apple.com> writes:
>>
>> The two spaces after the "1." come from the fact that Emacs thinks
>> it's a sentence-end period and hence it makes two spaces.  Emacs
>> always assumes two spaces after a sentence, when you do M-q.
>
> Are there variables that allow you to indicate what pattern an end of
> sentence should follow?  It seems this pattern isn't specific enough.
> If I indicate that a sentence usually isn't started with a number and
> a period on a new line then that should be enough to get it to do this
> only when it is a valid sentence, correct?

No, there is only something that matches an end of sentence.  See the
variables sentence-end, sentence-end-double-space, and
sentence-end-without-period.

With some care, you might be able to craft a regular expression that
matches period followed by two spaces only if something other than
digits precede the perdiod.  Hm.

Maybe you could set sentence-end to something like this:
"^.*[^0-9].*\\.  +"

The idea is to anchor it at beginning of line, then make sure that a
non-digit follows somewhere, and then the period, followed by two
spaces.

Not sure if that kind of plan will work.

>>> I much prefer a carriage return to indicate the end of the
>>> paragraph.  As it stands, you have to have a blank line between
>>> paragraphs to indicate the end of the paragraph.
>>
>> I don't understand this.  Emacs almost never uses carriage return
>> (^M) in a buffer.  And even inside a paragraph, every line ends with
>> a newline.
>>
>> There is longlines.el which can remove "superfluous" newlines
>> (within paragraphs) when writing the file and it re-adds them when
>> reading the file.
>
> Using "carriage return" was word processor speak.  I actually didn't
> know what Emacs uses for end of line/paragraph when you hit the return
> key.  Since looking at paragraph-start and paragraph-separate I come
> to the conclusion that it is looking for a line feed "\f" for
> paragraph-separate and a carriage return and line feed "\n\f" for
> paragraph-start.  Is this correct?  If not what does \n and \f mean?

For paragraph-separate, I see this in the source code: "[ \t\f]*$"
It means zero or more whitespace chars, then end of line.
Ie, a line that is empty or blank.

A whitespace char is space ( ), or tab (\t), or form-feed (\f).

Carriage return is \r.

paragraph-start has this default value: "\f\\|[ \t]*$"
It means a formfeed character, or an empty line, or a line consisting
of horizontal whitespace (space and tab) only.

The formfeed character does not have to be at the end of the line.

>>> It appears there may be some kind of continuation pattern being used
>>> for each variable.  I do understand basic regular expressions but I
>>> don't fully understand these patterns.
>>
>> Continuation pattern?
>
> The info docs said something about changing both variables if you
> change one.  I assumed this meant that both variable definitions
> together consisted of what makes up the end of a paragraph?  Is this
> not correct?

No, the relationship is not that simple.  paragraph-separate matches
lines that are between two paragraphs.

But sometimes, there is no line that is *between* two paragraphs,
because line number 9 is the last line of a paragraph and line number
10 is the first line of the next paragraph.  (There is no line number
nine-and-three-quarters in this world :-)

Therefore, paragraph-start should match everything that
paragraph-separate matches, plus those lines that start a paragraph
even though there might be no line between two paragraphs.

Does this make sense?

(I'm sure you can play all kinds of funny games by choosing strange
values for these variables.  I don't know what happens when the sets
of lines matched by the variables are disjoint, for instance.)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

[NEWBIE] Questions

[Robert Pollard]

Hi all,

I have tried finding the answers to these questions before posting.  I 
apologize up front for any of these questions that are in the docs that 
I missed.

1.	Is there a way to adjust the indent space provided by the auto-fill 
functionality between the topic number and the text.  As in the 
following example:
	1.   lkajsdf lsdfl sadfl dfljasldflkjsdflk asld fls
                 jsdfj asdfl lasdflj asdflj lsdf l jasdf lj sf  s
	Is there a way to adjust the space between the number 1. and the text? 
  It appears to be a default amount.

2.	If you have an outline and you need to move topics around is there a 
way to renumber the topics?
	i.e.
	2.    lkjasdf alkjdasf alsdf alsdjfl asldf
	1.    asdfsld fl sadf ls dfl lasdfl asdf
	3.    kljasdf lasdjf ljasdf asdj flkj asdf

3.	Why would a auto-fill not format the paragraph the way it does 99% 
of the other topics?
	i.e.
	The way it normally formats the paragraphs is:
	1.   asdfj asdfjljasdf lkjsdfj slkdjflj sdf sdfj lsdjf
	      sdf ksdf ;sadkf; ksdfk;sldk f;lsdl f;slk df;lask f
	On 2 occasions it formatted like:
	1.   sjdfj asdfsldjfljasld flkj asdfj alsdj fkasdlfj las
	sdjflasdjf lkjsdfk asdj lksdjflk asdlkf lsflk sdlfk sl
	I had to manually insert the tab/spaces for the second line.

4.	I prefer not to have the paragraph indicators as a line feed for end 
of the paragraph as it appears to be on default.  I much prefer a 
carriage return to indicate the end of the paragraph.  As it stands, 
you have to have a blank line between paragraphs to indicate the end of 
the paragraph.  The start of the paragraph variable (paragraph-start) 
appears to have the correct pattern for indicating how the paragraph 
should end for my purposes.  This is what my variable values are now:
	paragraph-start's value is "\f\\|[  	]*$"
	Local in buffer <buffer-name>; global value is "[  	\n\f]"

	paragraph-separate's value is "\f\\|[  	]*$"
	Local in buffer <buffer-name>; global value is "[  	\f]*$"
	The question's are:
	1.	Checking the space between the brackets it appears to be 2 spaces 
and then a tab.  Is this correct?  And, if so, why are these characters 
used?
	2.	Why is there a different value for global and the current buffer?  
It appears there may be some kind of continuation pattern being used 
for each variable.  I do understand basic regular expressions but I 
don't fully understand these patterns.

5.	I am running version 21.2.1 under Cygwin on an Intel system.  
Certain key equivalents that I have gotten used to over the time that I 
have been using Emacs are not working anymore.  I have to type the 
commands in instead.
They are:
C-x C-c	Quit Emacs
C-h v	Describe a variable
C-h i		Info docs
C-<spc>	Set a mark

Why would these key equivalents not work?  This is my first time for 
using Emacs in Cygwin but I thought the key equivalents would be the 
same on all systems.

I will try to limit the number of questions per posting but I do have 
others.

Thanks for your time,

Robert Pollard